MacFormat 1997 November/MacFormat 056 (November 1997).dmg/Shareware Plus/Developers/Sierra Engine in Director/Script

Text File | 1997-07-28 | 10.7 KB | 226 lines | [TEXT/TBB6]

-- This script was created by DaFedz, [e-mail], for use by anyone who wants to make
-- a Sierra style game in director, but can't get a good engine for the way the character
-- moves to the mouse click.  Any of this code may be used in a program, you don't even need
-- to give me credit (you can if you want to, in which case just include my name and email
-- address).  I hope this can be of some help.  The only thing I request is that I get a free
-- copy of any games you make using this engine.  Again, this is purely optional, but I will
-- use all such positive or negative feedback to determine whether I will make other public
-- domain projects like this one in the future.

-- I'm fairly sure that this script will work in any version of director past version 4.
-- It was made in Director 6, but I'm not using any advanced Lingo that wasn't available
-- in 4 or 5.

--                       --->•!!! MAKING GAMES IN DIRECTOR !!!•<---

-- What's this?  Director can't make fast games?  You can't have truly interactive games
-- made by director that are still fast and fun?  You could never create a good engine for
-- a fun game in director, such as the Sierra-style engine?  You've tried to do it and always
-- came up with an engine that is very inaccurate because of the rounding done to your numbers
-- to fit the pixels on the screen?

-- WRONG!!

-- It's true that it's harder with the scripting language Lingo to make and engine where
-- a sprite moves from a stationary position to a click location, but it is possible, even
-- with a reasonably short amount of coding.  The way I worked it out is that the sprite
-- has 16 basic angles to move on a 360° scale.  The engine checks which of these angles
-- is best to reach the goal and moves in that direction, it then checks again and moves
-- again, checks then moves, checks then moves.  This way the sprite will always reach the
-- click point accurately in a more or less straight line.

--     4     1       2
--     |     /      /     This is a crude ASCII representation of one quadrant on a 360°
--     |    |     /       scale that the sprite can move in along with the numbers used
--     |   /    /    3    in the variable that stores which angle the sprite is moving in.
--     |  |   /   __/     The ratios of vertical movement to horizontal movement are:
--     | /  /  __/
--     || / __/           0) 1:0  1) 1:2  2) 1:1  3) 2:1  4) 0:1
--     |/__/
--     *-------------0    If you take the numbers in between these ratios you come up with
--                        a range around each angle.  This is the range that decides what
-- angle to use.  If the click falls within a range around angle 2 (boundaries being between
-- angles 1 and 2 as well as angles 3 and 2) then angle 2 will be used for the next move.

-- I found that my engine where the ratio derived directly from the origin and destination
-- was used to move the sprite was very inaccurate and unpredictable.  The sprite would often
-- end up over 100 pixels away from where I clicked.  I found that limiting the angles of
-- movement to 16 greatly increased the accuracy as well as useability of the engine.  Using
-- an engine like this it would not be hard to incorporate keyboard control of the sprite,
-- boundaries, and areas where the sprite moves around rather than through.

-- Enough comment header, on to the actual coding.

global mhorz    --The horizontal position of the clock location
global mvert    --The vertical position of the click location
global hdist    --The horizontal distance from the sprite to the click location
global vdist    --The vertical distance from the sprite to the click location
global svert    --The vertical position of the sprite
global shorz    --The horizontal position of the sprite
global hdir     --The horizontal direction the sprite must move in (1 or -1)
global vdir     --The vertical direction the sprite must move in (1 or -1)
global movetype --The type of movement (which angle)
global dratio   --The ratio to determin the angle needed to move in (vdist / hdist)
global ismoving --Boolean whether the sprite is currently moving or not
global t1var    --Variable used in type 1 angle to alternate the vertical movement
global t3var    --Variable used in type 3 angle to alternate the horizontal movement
global speed    --The speed at which the sprite moves (in pixels)

on startmovie
  set speed to 10 --Can vary, depends on smoothness wanted
  set the puppet of sprite 1 to true --Allows lingo to control the sprite in channel 1
  set ismoving to false --The sprite starts off stationary
end

-- Calcpath is the handler that calculates the angle that the sprite moves in.  It is
-- important to call this constantly while the sprite is moving (ismoving is true).
-- Since we want to be able to change the direction of the sprite even when it is already
-- moving, we should call calcpath on idle and make calcpath move the sprite one jump
-- at a time (a jump being the number of pixels that is in the speed variable).

on idle
  if ismoving = true then calcpath
end idle

on mousedown
  put the mousev into mvert --Gets the vertical location of the mouse
  put the mouseh into mhorz --Gets the horizontal location of the mouse
  put the locv of sprite 1 into svert --Gets the vertical location of the sprite
  put the loch of sprite 1 into shorz --Gets the horizontal location of the sprite
  calcpath --The first call to calculate the angle to move in
  updatestage
end

on calcpath

  -- Now to find the ratio we put the absolute value (non-negative number) of the
  -- mouse positions minus the sprite positions and divide them.  If the vertical
  -- difference is zero then we can automatically set the ange to type 4, and if
  -- the horizontal difference is zero we can set the type to 0.

  put abs(mvert - svert) into vdist
  put abs(mhorz - shorz) into hdist
  if float(vdist) <> 0 then
    if float(hdist) <> 0 then
      put float(vdist) / float(hdist) into dratio
    else
      put 0 into dratio
    end if
  else
    put 4 into dratio
  end if

  -- Now we test the ratio to decide the type of angle to use.  See the comment at
  -- the top of this script to see how this was derived.

  if dratio < 0.25 then set movetype to 0
  if dratio >= 0.25 and dratio < 0.75 then set movetype to 1
  if dratio >= 0.75 and dratio < 1.5 then set movetype to 2
  if dratio >= 1.5 and dratio < 4 then set movetype to 3
  if dratio >= 4 then set movetype to 4

  -- Now we check what quadrant the click was in compared to the sprite and set the
  -- vertical and horizontal directions accordingly (i.e., if the click was to the
  -- right of, and below the sprite, the horizontal will be negative and the vertical
  -- will be positive.)

  if mvert <= svert and mhorz >= shorz then
    set hdir to speed
    set vdir to -speed
  end if
  if mvert >= svert and mhorz <= shorz then
    set hdir to -speed
    set vdir to speed
  end if
  if mvert >= svert and mhorz >= shorz then
    set hdir to speed
    set vdir to speed
  end if
  if mvert <= svert and mhorz <= shorz then
    set hdir to -speed
    set vdir to -speed
  end if

  -- We now have all the information we need to move the sprite.

  set ismoving to true --Start it rolling
  set the castNum of sprite 1 to 1 --Here you can switch to an alternate cast member
  --                                 while the sprite is in motion
  moveit --This handler will move the sprite one jump as well as check to see when the
  --       sprite has reached it's destination
end

on moveit
  if movetype = 0 then --Angle zero moves the sprite 1 jump horizontally
    set shorz to shorz + hdir
  end if

  -- Angle 1 uses a variable that adds to 2 and resets constantly so that the sprite
  -- will only move once vertically every other time.  This way it will move
  -- horizontally twice for every vertical move.

  if movetype = 1 then
    set shorz to shorz + hdir
    set t1var to t1var + 1
    if t1var = 2 then
      set svert to svert + vdir
      set t1var to 0
    end if
  end if
  if movetype = 2 then --Moves one jump vertically and one horizontally
    set shorz to shorz + hdir
    set svert to svert + vdir
  end if

  -- Angle 3 uses a variable that adds to 2 and resets constantly so that the sprite
  -- will only move once horizontally every other time.  This way it will move
  -- vertically twice for every horizontal move.

  if movetype = 3 then
    set svert to svert + vdir
    set t3var to t3var + 1
    if t3var = 2 then
      set shorz to shorz + hdir
      set t3var to 0
    end if
  end if
  if movetype = 4 then --Moves the sprite one jump vertically
    set svert to svert + vdir
  end if
  set ismoving to true --Sets it so calcpath will be called on idle
  set the loch of sprite 1 to shorz --Sets the sprite to the new horizontal position
  set the locv of sprite 1 to svert --Sets the sprite to the new vertical position
  updatestage

  -- Now we must check to see if the sprite has completed it's move with the jump that
  -- it just made.  Since we are moving the sprite by a number of pixels other than 1,
  -- we have to check if the sprite is within close enough proximity to the click so that
  -- if one more jump were made by a number of pixels less than that of the current
  -- speed setting, the sprite would reach the click location.

  if shorz < mhorz + speed and shorz > mhorz - speed and svert < mvert + speed ¬
  and svert > mvert - speed then
    set ismoving to false --Stop it from moving
    set the castNum of sprite 1 to 3 --Return the sprite to the original cast member
    set the loch of sprite 1 to mhorz --Set the sprite to the click position exactly
    set the locv of sprite 1 to mvert --Set the sprite to the click position exactly
    updatestage
  end if
end

-- From here it should not be too hard to set boundaries of movement with another
-- handler as well as objects that act as obstacles.  I would suggest giving such
-- an object it's own script with it's boundaries along with what angle must be moved
-- at to pass that boundary.  The sprite can be made to move in this angle while
-- constantly checking if it's target can be reached by a straight line until it can.

-- Future projects that I might take on (in fact I will as soon as I start my game) are things
-- like scaling the sprite as it moves farther away and closer, a good modular method of
-- incorporating boundaries and obstacles, and perhaps attempting a crude (VERY crude) 3D
-- Doom-type engine using Director (this would be a feat).  Anyways, you can always feel free
-- to email me and ask me what I've done and I might provide you with some code to help you
-- along.  Anything for a fellow programmer!

-- Good luck, and happy Directing!
--                                                                      DaFedz
--                                                                      [e-mail]